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Next-Generation Vehicle-Initiated Emergency Calls 
Abstract 


This document describes how to use IP-based emergency services 
mechanisms to support the next generation of emergency calls placed 
by vehicles (automatically in the event of a crash or serious 
incident, or manually invoked by a vehicle occupant) and conveying 
vehicle, sensor, and location data related to the crash or incident. 
Such calls are often referred to as "Automatic Crash Notification" 
(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the 
case of manual trigger. The "Advanced" qualifier refers to the 
ability to carry a richer set of data. 


This document also registers a MIME media type and Emergency Call 
Data Type for the vehicle, sensor, and location data (often referred 
to as "crash data" even though there is not necessarily a crash) and 
an INFO package to enable carrying this and related data in SIP INFO 
requests. An external specification for the data format, contents, 
and structure is referenced in this document. 


This document reuses the technical aspects of next-generation Pan- 
European eCall (a mandated and standardized system for emergency 
calls by in-vehicle systems (IVSs) within Europe and other regions). 
However, this document specifies use of a different set of vehicle 
(crash) data, specifically, the Vehicle Emergency Data Set (VEDS) 
rather than the eCall Minimum Set of Data (MSD). This document is an 
extension of the IETF eCall document, with the primary differences 
being that this document makes the MSD data set optional and VEDS 
mandatory, and it adds attribute values to the metadata/control 
object to permit greater functionality. This document registers a 
new INFO package (identical to that registered for eCall but with the 
addition of the VEDS MIME type). This document also describes legacy 
(circuit-switched) ACN systems and their migration to next-generation 
emergency calling, to provide background information and context. 
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Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8148. 


Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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Gellens, et al. Standards Track [Page 2] 


RFC 8148 Vehicle-Initiated Emergency Calls May 2017 


Table of Contents 


1. Introduction Be ake al O ESA A PR i phy ree oe Se? hy O 2 4 
Zi STSrmimology: 23 te a a. “ead BOK. ee ge ER A, CRS A A ee We UAL La 6 
3. Document Scope Mi ae 8 
4. Overview of Legacy Deployment Models aE cay? a yn Zor Oa T ye SO 8 
5. Migration to Next Generation . . +. e e e e s e e e e . . . . 10 
6. Vehicre Data ce A Ta i bk: as cata HOS Mee. 13 
tye. Data Transporto a aia a eaa a a Bs OS a ee os a AC ee a A 
8. Call Setup .. goua ted (GEARY CA ee Sh aa a a SO ee. LO 
9. New Metadata/Control Values in aay A A AO wth tent a . pF 
9.1. New Values for the "action" Attribute .......... 18 
9.2. Example <request> Element ...........+.. +... 19 
9.3. The <ack> Element . . . . By a E de ar das SD 
9.4. The <capabilities> Element sin A hs WBE ste A A Be VE eee ee ZO 
10. Test Calls s. s s eo UGA We oat yep Wee GR Se gee cs, oe i ee ee ee ED 
11. Example Call iiitiation So cbs Se. hr ceeds: ae. A eh ae a AZ 
12): Security ConsideratidaS. eos iaa a e a a OY 
134 Privacy Considerations: e le ce: de e eo cd ee cas Ak DE A ad ak A ite 28 
14. IANA Considerations . . Ses BD ales ats Ged ge XK ed 428 
14.1. MIME Media Type Registration for 
application/EmergencyCall.VEDS+xml . . . . 28 
14.2. Registration of the "VEDS" Entry in the emergency ‘call 
Data: Types Registry Ja: sng e bo Bow a Se ee ew ee O 
14.3. New Action Values .. A NS) 
14.4. Emergency Call Static Messages Registry F shin te Pee cei Ew. L 
14.5. Emergency Call Vehicle Lamp IDs Registry . +. . . +. . . . 32 
14.6. Emergency Call Vehicle Camera IDs Registry . . +. +. +. . . 33 
14.7. The EmergencyCallData.VEDS INFO Package . +. +. +. +. +. +. +. 35 
15. References . . oo A as a id ci as dd “38 
15.1. Normative References So oy A t edn aes Oa ats BA a ae a 8 
15.2. Informative references: ve . . ss s e e e Pk a sa 39 
Acknowledgments . +. +. +. +. +... . +. . . . . eee eee l 40 
Authors’ Addresses . . s. soso ca ele e a ae os es 40 


Gellens, et al. Standards Track [Page 3] 


RFC 8148 Vehicle-Initiated Emergency Calls May 2017 


Le 


Introduction 


Emergency calls made by in-vehicle systems (e.g., automatically in 
the event of a crash or serious incident or manually by a vehicle 
occupant) assist in significantly reducing road deaths and injuries 
by allowing emergency services to respond quickly and appropriately 
to the specifics of the incident, often with better location 
accuracy. 


Drivers often have a poor location awareness, especially outside of 
major cities, at night, and when away from home (especially abroad). 
In the most crucial cases, the victim(s) might not be able to call 
because they have been injured or trapped. 


For more than two decades, some vehicles have been equipped with 
telematics systems that, among other features, place an emergency 
call automatically in the event of a crash or manually in response to 
an emergency call button. Such systems generally have on-board 
location determination systems that make use of satellite-based 
positioning technology, inertial sensors, gyroscopes, etc., which can 
provide an accurate position for the vehicle. Such built-in systems 
can take advantage of the benefits of being integrated into a 
vehicle, such as more power capacity, ability to have larger or 
specialized antenna, ability to be engineered to avoid or minimize 
degradation by vehicle glass coatings, interference from other 
vehicle systems, etc. Thus, the Public Safety Answering Point (PSAP) 
can be provided with a good estimate of where the vehicle is during 
an emergency. Vehicle manufacturers are increasingly adopting such 
systems, both for the safety benefits and for the additional features 
and services they enable (e.g., remote engine diagnostics, remote 
door unlock, stolen vehicle tracking and disabling, etc.). 


A common term for such systems is Automatic Crash Notification (ACN) 
or Advanced Automatic Crash Notification (AACN). Sometimes the word 
"Collision" is used instead of "Crash." In this document, "ACN" is 
used as a general term. ACN systems transmit some amount of data 
specific to the incident, referred to generally as "crash data" (the 
term is commonly used even though there might not have been a crash). 
While different systems transmit different amounts of crash data, 
standardized formats, structures, and mechanisms are needed to 
provide interoperability among systems and PSAPs. 


As of the date of this document, currently deployed in-vehicle 
telematics systems are circuit-switched and lack a standards-based 
ability to convey crash data directly to the PSAP (generally relying 
on either a human advisor or an automated text-to-speech system to 
provide the PSAP call taker with some crash data orally, or in some 
cases via a proprietary mechanism). In most cases, the PSAP call 
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taker needs to first realize that the call is related to a vehicle 
incident, and then listen to the data and transcribe it. Circuit- 
switched ACN systems are referred to here as "CS-ACN". 


The transition to next-generation emergency calling provides an 
opportunity to vastly improve the scope, breadth, reliability, and 
usefulness of crash data by transmitting a standardized set during 
call setup; the data can be processed by the PSAP in an integrated, 
automated way and made available to the call taker at call 
presentation. It also provides the ability for the call taker to 
request that a vehicle take certain actions, such as flashing lights 
or unlocking doors. In addition, vehicle manufacturers are provided 
an opportunity to take advantage of the same standardized mechanisms 
for data transmission and request processing for internal use if they 
wish (such as telemetry between the vehicle and a service center for 
both emergency and non-emergency uses, including location-based 
services, multimedia entertainment systems, remote door unlocking, 
remote diagnostics, and roadside assistance applications). 


Next-generation ACN provides an opportunity for such calls to be 
recognized and processed as such during call setup, and routed to an 
equipped PSAP where the vehicle data is available to assist the call 
taker in assessing and responding to the situation. Next-generation 
(IP-based) ACN systems are referred to here as NG-ACN. 


An ACN call can be initiated by a vehicle occupant or automatically 
initiated by vehicle systems in the event of a serious incident. 

(The "A" in "ACN" does stand for "Automatic", but the term is broadly 
used to refer to the class of calls that are placed by an in-vehicle 
system (IVS) or by Telematics Service Providers (TSPs) and that carry 
incident-related data as well as voice.) Automatically triggered 
calls indicate a car crash or some other serious incident (e.g., a 
fire). Manually triggered calls include reports of observed crashes 
or serious hazards (such as impaired drivers or roadway debris), 
requests for medical assistance, etc. 


The Association of Public-Safety Communications Officials (APCO) and 
the National Emergency Number Association (NENA) have jointly 
developed a standardized set of incident-related vehicle data for ACN 
use, called the Vehicle Emergency Data Set (VEDS) [VEDS]. Such data 
is often referred to as crash data although it is applicable in 
incidents other than crashes. 


This document describes how the IETF mechanisms for IP-based 
emergency calls are used to provide the realization of next- 
generation ACN. Although this specification is designed with the 
requirements for North America ACN in mind (and both APCO and NENA 
are based in the U.S.), it is specified generically such that the 
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technology can be reused or extended to suit requirements in other 
regions. 


This document reuses the technical aspects of next-generation Pan- 
European eCall (a mandated and standardized system for emergency 
calls by in-vehicle systems within Europe), as described in 


[RFC8147]. However, this document specifies use of a different set 
of vehicle (crash) data, specifically, VEDS rather than the eCall 
Minimum Set of Data (MSD). This document is an extension of 


[RFC8147], with the differences being that this document makes the 
MSD data set optional and VEDS mandatory, and it adds new attribute 
values to the metadata/control object defined in that document. This 
document also registers a new INFO package (identical to that defined 
in [RFC8147] with the addition of the VEDS MIME type). 


This document registers the application/EmergencyCallData.VEDS+xml 
MIME media type, the VEDS Emergency Call Data Type, and the 
EmergencyCallData.VEDS INFO package to enable carrying this and 
related data in SIP INFO requests. 


Section 6 introduces VEDS. Section 7 describes how VEDS data and 
metadata/control blocks are transported within NG-ACN calls. 
Section 8 describes how such calls are placed. 


These mechanisms are used to place emergency calls that are 
identifiable as ACN calls and that carry standardized crash data in 
an interoperable way. 


Calls by in-vehicle systems are placed using cellular networks, which 
might ignore location information sent by an originating device in an 
emergency call INVITE, instead substituting their own location 
information (although often determined in cooperation with the 
originating device). Standardized crash data structures typically 
include location as determined by the IVS. A benefit of this is that 
it allows the PSAP to see both the location as determined by the 
cellular network and the location as determined by the IVS. 


This specification inherits the ability to utilize test call 
functionality from Section 15 of [RFC6881]. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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This document reuses terminology defined in Section 3 of [RFC5012]. 
Additionally, we use the following abbreviations: 


3GPP: 3rd Generation Partnership Project 

AACN: Advanced Automatic Crash Notification 

ACN: Automatic Crash Notification 

APCO: Association of Public-Safety Communications Officials 

EENA: European Emergency Number Association 

ESInet: Emergency Services IP network 

GNSS: Global Navigation Satellite System (which includes 
various systems such as the Global Positioning System or 
GPS) 

IVS: In-Vehicle System 

MNO: Mobile Network Operator 

MSD: Minimum Set of Data 

NENA: National Emergency Number Association 

NG: Next Generation 

POTS: Plain Old Telephone Service (normal, circuit-switched 


voice calls) 


PSAP: Public Safety Answering Point 
TSP: Telematics Service Provider 
VEDS: Vehicle Emergency Data Set 


Because the endpoints of a next-generation ACN call are a PSAP and 
either an IVS or a TSP, to avoid repetitively writing "IVS or TSP", 
the term "IVS" is used to represent either an IVS or a TSP when 
discussing signaling behavior (e.g., sending VEDS data, sending a SIP 
INVITE request, receiving a SIP INFO request, etc.). 
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3; 


Document Scope 


This document is focused on how an ACN emergency call is set up and 
incident-related data (including vehicle, sensor, and location data) 
is transmitted to the PSAP using IETF specifications. For the direct 
model, this is the end-to-end description (between the vehicle and 
the PSAP). For the TSP model, this describes the call leg between 
the TSP and the PSAP, leaving the call leg between the vehicle and 
the TSP up to the entities involved (i.e., IVS and TSP vendors) who 
are free to use the same mechanism for both legs, or not. 


Note that Europe has a mandated and standardized system for emergency 
calls by in-vehicle systems. This Pan-European system is known as 
"eCall" and is the subject of a separate document, [RFC8147], which 
this document builds on. Vehicles designed to operate in multiple 
regions might need to support eCall as well as NG-ACN as described 
here. A vehicle IVS might determine whether to use eCall or ACN by 
first determining the region or country in which it is located (e.g., 
from a GNSS location estimate and/or identity of or information from 
an MNO). If other regions adopt other data formats, a multi-region 
vehicle might need to support those as well. This document adopts 
the call setup and other technical aspects of [RFC8147], which uses 
[RFC7852]; this makes it straightforward to use a different data set 
while keeping other technical aspects unchanged. Hence, both next- 
generation eCall (NG-eCall) and the NG-ACN mechanism described here 
are compatible, differing primarily in the specific data block that 
is sent (the eCall MSD in the case of NG-eCall and VEDS in this 
document) and some additions to the metadata/control data block. If 
other regions adopt their own vehicle data sets, this can be 
similarly accommodated without changing other technical aspects. 
Note that any additional data formats require a new INFO package to 
permit transport within SIP INFO requests. 


Overview of Legacy Deployment Models 


Legacy (circuit-switched) systems for placing emergency calls by 
in-vehicle systems generally have some ability to convey at least 
location and in some cases telematics data to the PSAP. Most such 
systems use one of three architectural models, which are described 
here as: "TSP", "direct", and "paired". These three models are 
illustrated below. 


In the TSP model, both emergency and routine TSP service calls are 
placed to a TSP; a proprietary technique (e.g., a proprietary in-band 
modem) is used for data transfer between the TSP and the vehicle. 
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In an emergency, typically a TSP agent verifies the emergency, 
bridges in the PSAP, and communicates location, crash data (such as 
impact severity and trauma prediction), and other data (such as the 
vehicle description) to the PSAP call taker orally (in some cases, a 
proprietary out-of-band interface is used). Since the TSP knows the 
location of the vehicle (from on-board GNSS and sensors), location- 
based routing is usually used to route to the appropriate PSAP. In 
some cases, the TSP is able to transmit location automatically, using 
Similar techniques as for wireless calls. A three-way voice call is 
generally established between the vehicle, the TSP, and the PSAP, 
allowing communication between the PSAP call taker, the TSP agent, 
and the vehicle occupants (who might be unconscious). 


Figure 1: Legacy TSP Model 


In the paired model, the IVS uses a local link (typically Bluetooth 
[Bluetooth]) with a previously paired handset to establish an 
emergency call with the PSAP (by dialing a standard emergency number; 
9-1-1 in North America) and then communicates location data to the 
PSAP via text-to-speech; crash data might or might not be conveyed 
also using text-to-speech. Some such systems use an automated voice 
prompt menu for the PSAP call taker (e.g., "this is an automatic 
emergency call from a vehicle; press 1 to open a voice path to the 
vehicle; press 2 to hear the location read out") to allow the call 
taker to request location data via text-to-speech. 


/ +----+ 911/etc. voice call via handset +------ + 
l 
(Note: "HS" is handset.) 

Figure 2: Legacy Paired Model 


In the direct model, the IVS directly places an emergency call with 
the PSAP by dialing a standard emergency number (9-1-1 in North 


America). Such systems might communicate location data to the PSAP 
via text-to-speech; crash data might or might not be conveyed using 
text-to-speech. Some such systems use an automated voice prompt menu 


(e.g., "this is an automatic emergency call from a vehicle; press 1 
to open a voice path to the vehicle; press 2 to hear the location 
read out") to allow the call taker to request location data via 
text-to-speech. 
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LARSEN 911/etc. voice call via IVS +------ + 
||| mvs || |---------------------------------------- >| PSAP 
\\\----/// location via text-to-speech +------ + 


Figure 3: Legacy Direct Model 
5. Migration to Next Generation 


The migration of emergency calls placed by in-vehicle systems to 
next-generation (all-IP) technology per this document provides a 
standardized mechanism to identify such calls and to convey crash 
data with the call setup, as well as enabling additional 
communications modalities and enhanced functionality. This allows 
ACN calls and crash data to be automatically processed by the PSAP 
and made available to the call taker in an integrated, automated way. 
Because the crash data is carried in the initial SIP INVITE (per 
[RFC7852]) the PSAP can present it to the call taker simultaneously 
with the appearance of the call. The PSAP can also process the data 
to take other actions (e.g., if multiple calls from the same location 
arrive when the PSAP is busy and a subset of them are NG-ACN calls, a 
PSAP might choose to store the information and reject the calls, 
since the IVS will receive confirmation that the information has been 
successfully received; a PSAP could also choose to include a message 
stating that it is aware of the incident and responders are on the 
way, and a PSAP could call the vehicle back when a call taker is 
available). 


The migration of origination devices and networks, PSAPs, emergency 
services networks, and other telephony environments to next 
generation technology provides enhanced interoperability and 
functionality, especially for emergency calls carrying additional 
data such as vehicle crash data. (In the U.S., a network 
specifically for emergency responders is being developed. This 
network, FirstNet, will be next generation from the start, enhancing 
the ability for data exchange between PSAPs and responders.) 


NG-ACN calls can be recognized as such during call set-up; they can 
be routed to a PSAP that is prepared both technically and 
operationally to handle such calls, and the vehicle-determined 
location and crash data can be processed automatically by the PSAP 
and made available to the call taker simultaneously with the call 
appearance. Enhanced functionality includes the ability for the PSAP 
call taker to request the vehicle to take an action, such as sending 
an updated set of data, conveying a message to the occupants, 
flashing lights, unlocking doors, etc. 
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Vehicle manufacturers using the TSP model can choose to take 
advantage of the same mechanism to carry telematics data and requests 
and responses between the vehicle and the TSP for both emergency and 
non-emergency calls as are used for the interface with the PSAP. 


An IVS establishes a next-generation emergency call (see [RFC6443] 
and [RFC6881]) with an initial INVITE containing a Request-URI 
indicating an ACN emergency Call and Call-Info header fields 
indicating that both vehicle crash and capabilities data are 
included; the IVS typically does not perform routing or location 
queries (relying on the MNO for this). 


[RFC8147] registers new service URN children within the "sos" 
subservice. These URNs request NG-ACN resources and differentiate 
between manually and automatically triggered NG-ACN calls (which 
might be subject to different treatment depending on policy). The 
two service URNs registered in [RFC8147] are 
"urn:service:sos.ecall.automatic" and "urn:service:sos.ecall.manual". 
The same service URNs are used for ACN as for eCall since in any 
region only one of these is supported, making a distinction 
unnecessary. (Further, PSAP equipment might support multiple data 
formats, allowing a PSAP to handle a vehicle that erroneously sent 
the wrong data object.) 


Note that in North America, routing queries performed by clients 
outside of an ESInet typically treat all sub-services of "sos" 
identically to "sos" with no sub-service. However, the Request-URI 
header field retains the full sub-service; route and handling 
decisions within an ESInet or PSAP can take the sub-service into 
account. For example, in a region with multiple cooperating PSAPs, 
an NG-ACN call might be routed to a PSAP that is NG-ACN capable, or 
one that specializes in vehicle-related incidents. 


Migration of the three architectural models to next generation 
(all-IP) is described below. 


In the TSP model, the IVS transmits crash and location data to the 
TSP either by reusing the mechanisms and data objects described in 
this document or by using a proprietary mechanism. In an emergency, 
the TSP bridges in the PSAP, and the TSP transmits crash and other 
data to the PSAP using the mechanisms and data objects described in 
this document. There is a three-way call between the vehicle, the 
TSP, and the PSAP, allowing communication between the PSAP call 
taker, the TSP agent, and the vehicle occupants (who might be 
unconscious). The TSP relays PSAP requests and vehicle responses. 
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proprietary 
LEPE NNN or standard >an + standard Jana + 
||| rvs || |------------------- >| TSP |------------------- >| PSAP 
\\\----///  crashtother data +----- + crashtother data +------ + 


Figure 4: Next-Generation TSP Model 


The vehicle manufacturer and the TSP can choose to use the same 
mechanisms and data objects on the left call leg in Figure 4 as on 
the right. (Note that the TSP model can be more difficult when the 
vehicle is in a different country than the TSP (e.g., a US resident 
driving in Canada) because of the additional complexity in choosing 
the correct PSAP based on vehicle location performed by a TSP in a 
different country.) 


In the direct model, the IVS communicates crash data to the PSAP 
directly using the mechanisms and data objects described in this 


document. 
///----\\\ NG emergency call +------ + 
||| tvs || |----------------------------------------- >| PSAP 
\\\----/// crash + other data +------ + 


Figure 5: Next-Generation Direct Model 


In the paired model, the IVS uses a local link to a previously paired 
handset to establish an emergency call with the PSAP; it is unclear 
what facilities are or will be available for transmitting crash data 
through the link to the handset for inclusion in an NG emergency call 
and receiving additional data items from the response. Hence, 
manufacturers that use the paired model for legacy calls might choose 
to adopt either the direct or TSP model for next-generation calls. 


\ (undefined) ++ standard Homo + 


Figure 6: Next-Generation Paired Model 


Regardless of model, if the call is routed to a PSAP that is not 
NG-ACN capable, the PSAP ignores (or does not receive) the vehicle 
data. This is detectable by the IVS or TSP when the status response 
to the INVITE (e.g., 200 OK) lacks a metadata/control structure 


acknowledging receipt of the data [RFC8147]. The IVS or TSP then 
proceeds as it would for a CS-ACN call (e.g., oral conveyance of 
data). 
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6. 


Vehicle Data 


APCO and NENA have jointly developed a standardized set of incident- 
related vehicle data for ACN use, called the Vehicle Emergency Data 
Set (VEDS) [VEDS]. Such data is often referred to as crash data 
although it is applicable in incidents other than crashes. 


VEDS provides a standard data set for the transmission, exchange, and 
interpretation of vehicle-related data. A standard data format 
allows the data to be generated by an IVS or TSP and interpreted by 
PSAPs, emergency responders, and medical facilities. It includes 
incident-related information such as airbag deployment, location and 
compass orientation of the vehicle, spatial orientation of the 
vehicle (e.g., upright, on a side, roof, or bumper), sensor data that 
can indicate the potential severity of the crash and the likelihood 
of severe injuries to the vehicle occupants, etc. This data better 
informs the PSAP and emergency responders as to the type of response 
that might be needed. Some of this information has been included in 
U.S. government guidelines for field triage of injured patients 
[triage-2008] [triage-2011]. These guidelines are designed to help 
responders identify the potential existence of severe internal 
injuries and to make critical decisions about how and where a patient 
needs to be transported. 


VEDS is an XML structure (see [VEDS]) transported in SIP using the 
application/EmergencyCallData.VEDS+xml MIME media type. 


If new data blocks are needed (e.g., in other regions or for enhanced 
data), the steps required during standardization are briefly 
summarized below: 


o A set of data is standardized by a Standards Development 
Organization (SDO) or appropriate organization. 


o A MIME media type for the crash data set is registered with IANA 

* If the data is specifically for use in emergency calling, the 

MIME media type is normally under the application type with a 
subtype starting with EmergencyCallData. 


* If the data format is XML, then by convention the name has a 
suffix of "+xml". 
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7. 


o The item is registered in the "Emergency Call Data Types" 
registry, as defined in Section 11.1.9 of [RFC7852]. 


* For emergency-call-specific formats, the registered name is the 
root of the MIME media type (not including the 
EmergencyCallData prefix and any suffix such as "+xml") as 
described in Section 4.1 of [RFC7852]. 


o A new INFO package is registered that permits carrying the new 
media type, the metadata/control object (defined in [RFC8147]), 
and for compatibility, the MSD and VEDS objects, in SIP INFO 
requests. 


Data Transport 


[RFC7852] establishes a general mechanism for including blocks of 
data within a SIP emergency call. This document makes use of that 
mechanism. This document also registers an INFO package (in 

Section 14.7) to enable NG-ACN-related data blocks to be carried in 
SIP INFO requests (per [RFC6086], new SIP INFO method usages require 
the definition of an INFO package). 


VEDS is an XML structure defined by APCO and NENA [VEDS]. It is 
carried in a body part with MIME media type application/ 
EmergencyCallData.VEDS+xml. 


An IVS transmits a VEDS data block (see [VEDS]) by including it as a 
body part of a SIP message per [RFC7852]. The body part is 
identified by its MIME media type (application/ 
EmergencyCallData.VEDS+xm1) in the Content-Type header field of the 
body part. The body part is assigned a unique identifier that is 
listed in a Content-ID header field in the body part. The SIP 
message is marked as containing the VEDS data by adding (or appending 
to) a Call-Info header field at the top level of the SIP message. 
This Call-Info header field contains a Content Identifier (CID) URL 
referencing the body part’s unique identifier and a "purpose" 
parameter identifying the data as a VEDS data block per the 
"Emergency Call Data Types" registry entry; the "purpose" parameter’s 
value is "EmergencyCallData.VEDS". A VEDS data block is carried in a 
SIP INFO request by using the INFO package defined in Section 14.7. 


A PSAP or IVS transmits a metadata/control object (see [RFC8147]) by 
including it in a SIP message as a MIME body part per [RFC7852]. The 
body part is identified by its MIME media type (application/ 
EmergencyCallData.Control+xm1) in the Content-Type header field of 
the body part. The body part is assigned a unique identifier that is 
listed in a Content-ID header field in the body part. The SIP 
message is marked as containing the metadata/control block by adding 
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(or appending to) a Call-Info header field at the top level of the 
SIP message. This Call-Info header field contains a CID URL 
referencing the body part’s unique identifier and a "purpose" 
parameter identifying the data as a metadata/control block per the 
"Emergency Call Data Types" registry entry; the "purpose" parameter’s 
value is "EmergencyCallData.Control". A metadata/control object is 
carried in a SIP INFO request by using the INFO package defined in 
Section 14.7. 


A body part containing a VEDS or metadata/control object has a 
Content-Disposition header field value containing "By-Reference" and 
is always enclosed in a multipart body part (even if it would 
otherwise be the only body part in the SIP message). 


An IVS initiating an NG-ACN call includes in the initial INVITE a 
VEDS data block and a metadata/control object informing the PSAP of 
its capabilities. The VEDS and metadata/control body parts (and 
Presence Information Data Format Location Object (PIDF-LO)) have a 
Content-Disposition header field with the value "By-Reference; 
handling=optional". Specifying handling=optional prevents the INVITE 
from being rejected if it is processed by a legacy element (e.g., a 
gateway between SIP and circuit-switched environments) that does not 
understand the VEDS or metadata/control (or PIDF-LO) objects. The 
PSAP creates a metadata/control object acknowledging receipt of the 
VEDS data and includes it in the SIP final response to the INVITE. 
The metadata/control object is not included in provisional (e.g., 
180) responses. 


If the IVS receives an acknowledgment for a VEDS data object with 
received=false, this indicates that the PSAP was unable to properly 
decode or process the VEDS. The IVS action is not defined (e.g., it 
might only log an error). Since the PSAP is able to request an 
updated VEDS during the call, if an initial VEDS is unsatisfactory in 
any way, the PSAP can choose to request another one. 


A PSAP can request that the vehicle send an updated VEDS data block 
during a call. To do so, the PSAP creates a metadata/control object 
requesting VEDS data and includes it as a body part of a SIP INFO 
request sent within the dialog. The IVS then includes an updated 
VEDS data object as a body part of a SIP INFO request and sends it 
within the dialog. If the IVS is unable to send the VEDS for any 
reason, it instead sends a metadata/control object containing an 
<ack> element acknowledging the request and containing an 
<actionResult> element with the "success" parameter set to "false" 
and a "reason" parameter (and optionally a "details" parameter) 
indicating why the request cannot be accomplished. Per [RFC6086], 
metadata/control objects and VEDS data are sent using the INFO 
package defined in Section 14.7. In addition, to align with the way 
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a VEDS or metadata/control block is transmitted in a SIP message 
other than a SIP INFO request, one or more Call-Info header fields 
are included in the SIP INFO request referencing the VEDS or 
metadata/control block. See Section 14.7 for more information on the 
use of SIP INFO requests within NG-ACN calls. 


Any metadata/control object sent by a PSAP can request that the 
vehicle perform an action (such as sending a data block, flashing 
lights, providing a Camera feed, etc.). The IVS sends an 
acknowledgment for any request other than a successfully executed 
send-data action. Multiple requests with the same "action:" value 
MUST be sent in separate metadata/control body parts (to avoid any 
ambiguity in the acknowledgment). For each metadata/control block 
received containing one or more <request> elements (except for 
successfully executed send-data requests), the IVS sends a metadata/ 
control object containing an <ack> element acknowledging the received 
metadata/control block, containing an <actionResult> element per 
<request> element. 


If the IVS is aware that VEDS data it sent previously has changed, it 
MAY send an unsolicited VEDS in any convenient SIP message, including 
a SIP INFO request during the call. The PSAP sends an acknowledgment 
for an unsolicited VEDS object; if the IVS sent the unsolicited VEDS 
in a SIP INFO request, the acknowledgment is sent in a new SIP INFO 
request; otherwise, it is sent in the reply to the SIP request 
containing the VEDS. 


8. Call Setup 


An IVS initiating an NG-ACN call sends a SIP INVITE request using one 
of the SOS sub-services "SOS.ecall.automatic" or "SOS.ecall.manual" 
in the Request-URI. This SIP INVITE request includes standard sets 
of both crash and capabilities data as described in Section 7. 


Entities along the path between the vehicle and the PSAP are able to 
identify the call as an ACN call and handle it appropriately. The 
PSAP is able to identify the crash and capabilities data included in 
the SIP INVITE request by examining the Call-Info header fields for 
"purpose" parameters whose values start with EmergencyCallData. The 
PSAP is able to access the data it is capable of handling and is 
interested in by checking the "purpose" parameter values. 


This document extends [RFC8147] by reusing the call setup and other 
normative requirements with the exception that in this document, 
support for the eCall MSD is OPTIONAL and support for VEDS is 
REQUIRED. This document also adds new attribute values to the 
metadata/control object defined in [RFC8147]. 
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dis 


New Metadata/Control Values 


This document adds new attribute values to the metadata/control 
structure defined in [RFC8147]. 


In addition to the base usage from the PSAP to the IVS to acknowledge 
receipt of crash data, the <ack> element is also contained in a 
metadata/control block sent by the IVS to the PSAP. This is used by 
the IVS to acknowledge receipt of a request by the PSAP and indicate 
if the request was carried out when that request would not otherwise 
be acknowledged (if the PSAP requests the vehicle to send data and 
the vehicle does so, the data serves as a success acknowledgment) ; 
see Section 8 for details. 


The <capabilities> element is used in a metadata/control block sent 
from the IVS to the PSAP (e.g., in the initial INVITE) to inform the 
PSAP of the vehicle capabilities. Child elements contain all actions 
and data types supported by the vehicle and all available lamps 
(lights) and cameras. 


New request values are added to the <request> element to enable the 
PSAP to request the vehicle to perform additional actions. 


Mandatory Actions (the IVS and the PSAP MUST support): 


o Transmit data object (VEDS MUST be supported; MSD MAY be 
supported) 


Optional Actions (the IVS and the PSAP MAY support): 


Display and/or play static (pre-defined) message 

Display and/or speak dynamic text (text supplied in action) 
Flash or turn on or off a lamp (light) 

Honk horn 

Lock or unlock doors 

Enable a camera 


000000 


The <ack> element indicates the object being acknowledged (i.e., a 
data object or a metadata/control block containing <request> 
elements) and reports success or failure. 


The <capabilities> element has child <request> elements indicating 
the actions (including data types, lamps (lights), and cameras) 
supported by the IVS. 


The <request> element contains attributes to indicate the request and 
to supply any needed information, and it MAY contain a <text> child 
element to contain the text for a dynamic message. The "action" 
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attribute is mandatory and indicates the specific action. [RFC8147] 
established an IANA registry to contain the allowed values; this 
document adds new values to that registry in Table 1. 


9.1. New Values for the "action" Attribute 
The following new "action" values are defined: 


msg-static: displays or plays a pre-defined message (translated as 
appropriate for the language of the vehicle’s interface). A 
registry is created in Section 14.4 for messages and their IDs. 
Vehicles include the highest registered message in their 
<capabilities> element to indicate support for all messages up to 
and including the indicated value. A registry of message 
identification values is defined in Section 14.4. There is only 
one static message initially defined (listed in Table 2). Because 
all compliant vehicles are expected to support all static messages 
translated into all languages supported by the vehicle, it is 
important to limit the number of such messages. Therefore, this 
registry operates under "Specification Required" rules as defined 
in [RFC5226], which requires a stable, public document and implies 
expert review of the publication. 


msg-dynamic: displays or speaks (via text-to-speech) a message 
contained in a child <text> element within the request. 


honk: sounds the horn. 


lamp: flashes a lamp (light) or turns it on or off. The lamp is 
identified by a lamp ID token contained in an "element-id" 
attribute of the request. The desired state of the lamp is either 
"on", "off", or "flash" as indicated in a "requested-state" 


attribute. The duration of the lamp’s requested state is 
specified in a "persistence" attribute. A registry of lamp 
identification values is defined in Section 14.5. The initial 


values (listed in Table 3) are head, interior, fog-front, 
fog-rear, brake, brake-center, position-front, position-rear, 
turn-left, turn-right, and hazard. 


enable-camera: adds a one-way media stream (established via SIP 
re-INVITE sent by the vehicle) to enable the PSAP call taker to 
view a feed from a Camera. A registry of camera identification 
values is defined in Section 14.6. The initial values (listed in 
Table 4) are backup, left-rear, right-rear, forward, rear-wide, 
lane, interior, night-front, night-rear, night-left, and night- 
right. 
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door-lock: locks or unlocks all door locks. A "requested-state" 
attribute contains either "locked" or "unlocked" to indicate if 
the doors are to be locked or unlocked. 


Note that there is no "request" action to play dynamic media (such as 
an audio message). The PSAP can send a SIP re-INVITE to establish a 
one-way media stream for this purpose. 


Example <request> Element 


<?xml version="1.0" encoding="UTF-8"?> 

<EmergencyCallData.Control 
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<request action="send-data" datatype="VEDS"/> 
<request action="lamp" element-id="hazard" 
requested-state="flash" persistence="PT1H"/> 
<request action="msg-static" int-id="1"/> 
<request action="msg-dynamic"> 
<text>Remain calm. Help is on the way.</text> 
</request> 


</EmergencyCallData.Control> 


Figure 7: <request> Example 


The <ack> Element 


The <ack> element is transmitted by the PSAP to acknowledge 
unsolicited data sent by the IVS and transmitted by the IVS to 
acknowledge receipt of a <request> element other than a successfully 
performed "send-data" request (e.g., a request to display a message 
to the vehicle occupants is acknowledged, but a request to transmit 
VEDS data is not, since the transmitted VEDS serves as 
acknowledgment). An <ack> element sent by an IVS references the 
unique ID of the metadata/control object containing the request(s), 
and for each request being acknowledged, it indicates whether the 
request was successfully performed, and if not, it indicates why not. 
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9.3.1. Examples of the <ack> Element 


<?xml version="1.0" encoding="UTF-8"?> 

<EmergencyCallData.Control 
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<ack ref="1234567890@atlanta.example.com"> 
<actionResult action="msg-dynamic" success="true"/> 
<actionResult action="lamp" success="false" reason="unable" 
details="The requested lamp is inoperable"/> 


</ack> 
</EmergencyCallData.Control> 
Figure 8: Example <ack> from IVS to PSAP 
9.4. The <capabilities> Element 


The <capabilities> element [RFC8147] is transmitted by the IVS to 
indicate its capabilities to the PSAP. 


The <capabilities> element contains a <request> child element per 
action supported by the vehicle. The vehicle MUST support sending 
the VEDS data object and so includes at a minimum a <request> child 
element with the "action" attribute set to "send-data" and the 
"supported-values" attribute containing all data blocks supported by 
the IVS, which MUST include "VEDS". All other actions are OPTIONAL. 


If the "msg-static" action is supported, a <request> child element 
with the "action" attribute set to "msg-static" is included, with the 
"int-id" attribute set to the highest supported static message 
supported by the vehicle. A registry is created in Section 14.4 to 
map "int-id" values to static text messages. By sending the highest 
supported static message number in its <capabilities> element, the 
vehicle indicates its support for all static messages in the registry 
up to and including that value. 


If the "lamp" action is supported, a <request> child element with the 
"action" attribute set to "lamp" is included, with the "supported- 
values" attribute set to all supported lamp IDs. A registry is 
created in Section 14.5 to contain lamp ID values. 


If the "enable-camera" action is supported, a <request> child element 
with the "action" attribute set to "enable-camera" is included, with 
the "supported-values" attribute set to all supported camera IDs. A 
registry is created in Section 14.6 to contain camera ID values. 
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9.4.1. Example <capabilities> Element 


<?xml version="1.0" encoding="UTF-8"?> 

<EmergencyCallData.Control 
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<capabilities> 
<request action="send-data" supported-values="VEDS"/> 
<request action="lamp" 
supported-values="head; interior; fog-front; 
fog-rear; brake; position-front;position-rear; 
turn-left;turn-right;hazard"/> 
<request action="msg-static" int-id="3"/> 
<request action="msg-dynamic"/> 
<request action="honk"/> 
<request action="enable-camera" 
supported-values="backup; interior"/> 
<request action="door-lock"/> 
</capabilities> 


</EmergencyCallData.Control> 
Figure 9: <capabilities> Example 
10. Test Calls 


An NG-ACN test call is a call that is recognized and treated to some 
extent as an NG-ACN call but is not given emergency call treatment 
nor handled by a PSAP call taker. The specific handling of test 
NG-ACN calls is outside the scope of this document; typically, the 
test call facility allows the IVS, user, or TSP to verify that an 
NG-ACN call can be successfully established with voice and/or other 
media communication. The IVS might also be able to verify that the 
crash data was successfully received. 


This document builds on [RFC8147], which inherits the ability to 


utilize test call functionality from Section 15 of [RFC6881]. A 
service URN starting with "test." indicates a test call. Per 
[RFC8147], "urn:service:test.sos.ecall" is used for test NG-ACN 
Calls. 


MNOs, emergency authorities, ESInets, and PSAPs handle a vehicle call 
requesting the "test" service URN so that the desired functionality 
is tested, but this is outside the scope of this document. (One 
possibility is that MNOs route such calls as non-emergency calls to 
an ESInet, which routes them to a PSAP that supports NG-ACN calls; 
the PSAP accepts test calls, sends a crash data acknowledgment, and 
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TI; 


plays an audio clip (for example, saying that the call reached an 
appropriate PSAP and the vehicle data was successfully processed) in 
addition to supporting media loopback per [RFC6881].) 


Note that since test calls are placed using "test" as the parent 
service URN and "sos" as a child, such calls are not treated as an 
emergency call, so some functionality might not apply (such as 
preemption or availability for devices lacking service 
("non-service-initialized" (NSI) devices) if those are available for 
emergency calls). 


Example Call Initiation 


Figure 10 shows an NG-ACN call initiation. The vehicle initiates an 
NG-ACN call using an MNO. The MNO routes the call to an ESInet, as 


for any emergency call. The ESInet routes the call to an appropriate 
NG-ACN-capable PSAP (using location information and the fact that it 
is an NG-ACN call). The call is processed by the Emergency Services 


Routing Proxy (ESRP), as the entry point to the ESInet. The ESRP 
routes the call to an appropriate NG-ACN-capable PSAP, where the call 
is handled by a call taker. (In deployments where there is no 
ESInet, the MNO itself routes the call directly to an appropriate 
NG-ACN-capable PSAP.) 


HO === === === ------ + 
| | 
+------------ + | +------—- + | 
PSAP2 | 
doo + 
| Originating| | | 
| Mobile | | +------ + doo + | 
Vehicle-->| Network |--|->| ESRP |--->| PSAP1 --> Call Taker | | 
| | | +------ + +---------------------—- + | 
| | 
Ho + +------- + 
| PSAP3 | | 
| to + | 
| | 
| | 
ESInet 
HO === === === ------- + 


Figure 10: Example Call Initiation 


Figure 11 illustrates an example SIP emergency call INVITE request as 
generated by the IVS. It includes a PIDF-LO with vehicle-determined 
location information, a VEDS block with crash data, and a metadata/ 
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control block with capabilities data. The INVITE has a request URI 
containing the urn:service:sos.ecall.automatic service URN. For 
brevity, the example VEDS block does not show VEDS location 
information, although this is generally present. 


The example VEDS data structure shows information about a crashed 
vehicle. The example communicates that the car is a model year 2015 
Saab 9-5 (a car that does not exist). The front airbag deployed as a 
consequence of the crash. The <VehicleBodyCategoryCode> indicates 
that the crashed vehicle is a passenger car (the code is set to 
"101") and that it is not a convertible (the <ConvertibleIndicator> 
value is set to "false"). 


The <VehicleCrashPulse> element provides further information about 
the crash, namely that the force of impact based on the change in 
velocity over the duration of the crash pulse was 100 MPH. The 
principal direction of the force of the impact is set to "12" (which 
refers to 12 o’clock, corresponding to a frontal collision). This 
value is in the <CrashPulsePrincipalDirectionOfForceValue> element. 


The <CrashPulseRolloverQuarterTurnsValue> indicates the number of 
quarter turns in concert with a rollover expressed as a number; in 
our case l. 


No roll bar was deployed, as indicated in 
<VehicleRollbarDeployedIndicator> being set to "false". 


Next, there is information indicating seat belt and seat sensor data 
for individual seat positions in the vehicle. In our example, 
information from the driver seat is available (value "1" in the 
<VehicleSeatLocationCategoryCode> element) showing that the seat belt 
was monitored (<VehicleSeatbeltMonitoredIndicator> element), the seat 
belt was fastened (<VehicleSeatbeltFastenedIndicator> element), and 
the seat sensor determined that the seat was occupied 
(<VehicleSeatOccupiedIndicator> element). 


The weight of the vehicle when empty is listed as 600 kilograms in 
our example. 


The <SevereInjuryIndicator> element is set to "true", indicating a 
likelihood that a vehicle occupant has suffered a severe injury 
requiring immediate trauma care. 


Additional information is provided, including the presence of fuel 
leakage (<FuelLeakingIndicator> element), an indication whether the 
vehicle was subjected to multiple impacts (<MultipleImpactsIndicator> 
element), the orientation of the vehicle at final rest 
(<VehicleFinalRestOrientationCategoryCode> element), and an 
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indication that no parts of the vehicle are currently detected as 
being on fire (the <VehicleFireIndicator> element). 


INVITE urn:service:sos.ecall.automatic SIP/2.0 
To: urn:service:sos.ecall.automatic 
From: <sip:+13145551111@example.com>; tag=9fxced76sl1 
Call-ID: 3848276298220188511@atlanta.example.com 
Geolocation: <cid:target123@example.com> 
Geolocation-Routing: no 
Call-Info: <cid:1234567890@atlanta.example.com>; 
purpose=EmergencyCallData.VEDS 
Call-Info: <cid:1234567892@atlanta.example.com>; 
purpose=EmergencyCallData.Control 
Accept: application/sdp, application/pidf+xml, 
application/EmergencyCallData.Control+xml 
Recv-Info: EmergencyCallData.eCall 
Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, 
SUBSCRIBE, NOTIFY, UPDATE 
CSeq: 31862 INVITE 
Content-Type: multipart/mixed; boundary=boundaryl 
Content-Length: 


--boundaryl 
Content-Type: application/sdp 


...Session Description Protocol (SDP) goes here 


--boundaryl 

Content-Type: application/pidf+xml 

Content-ID: <target123@atlanta.example.com> 
Content-Disposition: by-reference; handling=optional 


<?xml version="1.0" encoding="UTF-8"?> 
<presence 
xmlns="urn:ietf:params:xml:ns:pidf" 
xml1lns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:gp="urn:ietf:params:xml:ns:pidf:geoprivl0" 
xml1ns:dyn="urn:ietf:params:xml:ns:pidf:geoprivl10:dynamic" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs="http://www.opengis.net/pidflo/1.0" 
entity="sip:+13145551111@example.com"> 
<dm:device id="123"> 
<gp:geopriv> 
<gp:location-info> 
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> 
<gml :pos>-34.407 150.883</gm1l:pos> 
</gml:Point> 
<dyn:Dynamic> 
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<dyn:heading>278</dyn:heading> 
<dyn:direction></dyn:direction> 
</dyn:Dynamic> 
</gp:location-info> 
<gp:usage-rules/> 
<method>gps</method> 
</gp:geopriv> 
<timestamp>2012-04-5T10:18:29Z</timestamp> 
<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID> 


</dm:device> 
</presence> 


--boundaryl 

Content-Type: application/EmergencyCallData.VEDS+xml 
Content-ID: <1234567890@atlanta.example.com> 
Content-Disposition: by-reference; handling=optional 


<?xml version="1.0" encoding="UTF-8"?> 
<AutomatedCrashNotification xmlns="http://www.veds.org/acn/1.0" 


<Crash> 
<CrashVehicle> 


Gellens, 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<ItemMakeName xmlns="http://niem.gov/niem/niem-core/2.0"> 
Saab 

</ItemMakeName> 

<ItemModelName xmlns="http://niem.gov/niem/niem-core/2.0"> 
9-5 

</ItemModelName> 

<ItemModelYearDate 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
2015 

</ItemModelYearDate> 

<Airbag> 
<AirbagCategoryCode>FRONT</AirbagCategoryCode> 
<AirbagDeployedIndicator>true 
</AirbagDeployedIndicator> 

</Airbag> 

<Convertiblelndicator>false</Convertiblelndicator> 

<PowerSourceCategoryCode>MAIN</PowerSourceCategoryCode> 

<VehicleBodyCategoryCode 
xmlns="http://niem.gov/niem/domains/jxdm/4.1"> 
101 

</VehicleBodyCategoryCode> 

<VehicleCrashPulse> 
<CrashPulseChangeInVelocityMeasure> 

<MeasurePointValue 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
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100 
</MeasurePointValue> 
<MeasureUnitText 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
MPH</MeasureUnitText> 
</CrashPulseChangeInVelocityMeasure> 
<CrashPulsePrincipalDirectionOfForceValue>12 
</CrashPulsePrincipalDirectionOfForceValue> 
<CrashPulseRolloverQuarterTurnsValue>1 
</CrashPulseRolloverQuarterTurnsValue> 
</VehicleCrashPulse> 
<VehicleRollbarDeployedIndicator>false 
</VehicleRollbarDeployedIndicator> 
<VehicleSeat> 
<VehicleSeatLocationCategoryCode>1 
</VehicleSeat LocationCategoryCode> 
<VehicleSeatOccupiedIndicator>true 
</VehicleSeatOccupiedIndicator> 
<VehicleSeatbeltFastenedIndicator>true 
</VehicleSeatbeltFastenedIndicator> 
<VehicleSeatbeltMonitoredIndicator>true 
</VehicleSeatbeltMonitoredIndicator> 
</VehicleSeat> 
<VehicleUnladenWeightMeasure 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
<MeasurePointValue 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
600 
</MeasurePointValue> 
<MeasureUnitText 
xmlns="http://niem.gov/niem/niem-core/2.0"> 
kilogram 
</MeasureUnitText> 
</VehicleUnladenWeightMeasure> 


</CrashVehicle> 
<FuelLeakingIndicator>true</FuelLeakingIndicator> 
<MultipleImpactsIndicator>false</MultipleImpactsIndicator> 
<SevereInjuryIndicator>true</SevereInjuryIndicator> 
<VehicleFinalRestOrientationCategoryCode>Driver 
</VehicleFinalRestOrientationCategoryCode> 
<VehicleFireIndicator>false</VehicleFireIndicator> 
</Crash> 


</AutomatedCrashNotification> 


--boundaryl 

Content-Type: application/EmergencyCallData.Control+xml 
Content-ID: <1234567892@atlanta.example.com> 
Content-Disposition: by-reference; handling=optional 
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<?xml version="1.0" encoding="UTF-8"?> 

<EmergencyCallData.Control 
xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<capabilities> 
<request action="send-data" supported-datatypes="VEDS"/> 
<request action="lamp" 
supported-values="head; interior; fog-front; fog-rear; 
brake; position-front;position-rear;turn-left; 
turn-right;hazard"/> 
<request action="msg-static" int-id="3"/> 
<request action="msg-dynamic"/> 
<request action="honk"/> 
<request action="enable-camera" 
supported-values="backup; interior"/> 
<request action="door-lock"/> 
</capabilities> 


</EmergencyCallData.Control> 

--boundaryl-- 

Figure 11: SIP INVITE for a Vehicle-Initiated Emergency Call 
12. Security Considerations 


Since this document relies on [RFC8147] and [RFC7852], the security 
considerations described in those specifications apply here. The 
security considerations of [RFC5069] apply as well. iImplementors are 
cautioned to read and understand the discussion in those documents. 


In emergency service systems where location data is supplied or 
determined with the assistance of an end host, it is possible that 
the location is incorrect, either intentionally (e.g., in a denial- 
of-service attack against the emergency services infrastructure) or 
due to a malfunctioning device. The reader is referred to [RFC7378] 
for a discussion of some of these vulnerabilities. 


In addition to the security considerations discussion specific to the 
metadata/control object in [RFC8147], note that vehicles MAY decline 
to carry out any requested action (e.g., if the vehicle requires but 
is unable to verify the certificate used to sign the request). The 
vehicle MAY use any value in the reason registry to indicate why it 
did not take an action (e.g., the generic "unable" or the more 
specific "security-failure"). Because some actions carry more 
potential risk than others (e.g., unlocking a door versus flashing 
lights), vehicle policy MAY decline to carry out some requests in 
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some circumstances (e.g., decline a request to unlock doors, send an 
updated VEDS, or enable a Camera received in a vehicle-terminated 
call while carrying out such requests received in a vehicle-initiated 
emergency Call). 


Privacy Considerations 


Since this document builds on [RFC8147], which itself builds on 
[RFC7852], the data structures specified there, and the corresponding 
privacy considerations discussed there, apply here as well. The VEDS 
data structure contains optional elements that can carry identifying 
and personal information, both about the vehicle and about the owner, 
as well as location information, so it needs to be protected against 
unauthorized disclosure, as discussed in [RFC7852]. Local 
regulations may impose additional privacy protection requirements. 


The additional functionality enabled by this document, such as access 
to vehicle camera streams, Carries a burden of protection, so 
implementations need to be careful that access is only provided 
within the context of an emergency call or to an emergency services 
provider (e.g., by verifying that the request for camera access is 
signed by a certificate issued by an emergency services registrar). 


IANA Considerations 
This document registers the application/EmergencyCallData.VEDS+xml 
MIME media type and adds "VEDS" to the "Emergency Call Data Types" 
registry. This document adds to and creates sub-registries in the 
"Emergency Call Metadata/Control Data" registry created in [RFC8147]. 


In addition, this document registers a new INFO package. 


1. MIME Media Type Registration for application/ 
EmergencyCall.VEDS+xml 


IANA has registered a new MIME media type according to the procedures 
of [RFC6838] and guidelines in [RFC7303]. 


MIME media type name: application 
MIME subtype name: EmergencyCallData.VEDS+xml 
Mandatory parameters: none 


Optional parameters: charset 
Indicates the character encoding of enclosed XML. 
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Uses XML, which can employ 8-bit characters, depending on the 
character encoding used. See Section 3.2 of RFC 7303 


[RFC7303]. 


Security considerations: 


This media type is designed to carry vehicle crash data 


during an emergency call. 


This data can contain personal information including vehicle 
VIN, location, direction, etc. Appropriate precautions need 
to be taken to limit unauthorized access, inappropriate 
disclosure to third parties, and eavesdropping of this 
information. Please refer to Sections 9 and 10 of [RFC7852] 


for more information. 


When this media type is contained in a signed or encrypted 


body part, the enclosing multipart 


(e.g., multipart/signed 


or multipart/encrypted) has the same Content-ID as the data 
part. This allows an entity to identify and access the data 
blocks it is interested in without having to dive deeply 
into the message structure or decrypt parts it is not 
interested in. (The "purpose" parameter in a Call-Info 


header field identifies the data, 


and the CID URL points to 


the data block in the body, which has a matching Content-ID 


body part header field.) 
Interoperability considerations: None 


Published specification: [VEDS] 


Applications which use this media type: 


Additional information: None 
Magic Number: None 
File Extension: . xml 


Macintosh file type code: TEXT 


Emergency Services 


Persons and email addresses for further information: 
Randall Gellens, rg+ietf@randy.pensive.org; 
Hannes Tschofenig, Hannes.Tschofenig@gmx.net 


Intended usage: LIMITED USE 
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Author: 
This specification is a work item of the IETF ECRIT working 
group, with mailing list address <ecrit@ietf.org>. 


Change controller: The IESG <ietf@ietf.org> 


.2. Registration of the "VEDS" Entry in the Emergency Call Data Types 


Registry 


IANA has added "VEDS" to the "Emergency Call Data Types" registry, 
with a reference to this document; the "Data About" value is "The 
Call". The "Emergency Call Data Types" registry was established by 
[RFC7852]. 


3. New Action Values 
This document adds new values for the "action" attribute of the 


<request> element in the "Emergency Call Action" registry created by 
[RFC8147]. 


+--------------- +------------------------- + 
| Name | Description 

Ho +------------------------- + 
| msg-static | Section 9.1 of RFC 8148 | 
| | | 
| msg-dynamic | Section 9.1 of RFC 8148 | 
| | | 

honk Section 9.1 of RFC 8148 

| lamp | Section 9.1 of RFC 8148 | 
| | | 
| enable-camera | Section 9.1 of RFC 8148 | 
| | | 
| door-lock | Section 9.1 of RFC 8148 | 
Ho Ho + 


Table 1: Emergency Call Action Registry New Values 
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4. Emergency Call Static Messages Registry 


This document creates a new sub-registry Called "Emergency Call 
Static Messages" in the "Emergency Call Metadata/Control Data" 
registry established by [RFC8147]. Because compliant vehicles are 
expected to support all static messages translated into all languages 
supported by the vehicle, it is important to limit the number of such 
messages. As defined in [RFC5226], this registry operates under 
"Specification Required", which requires a stable, public document 
and implies expert review of the publication. The expert should 
determine that the document has been published by an appropriate 
emergency services organization (e.g., NENA, EENA, or APCO) or by the 
IETF with input from an emergency services organization, and that the 
proposed message is sufficiently distinguishable from other messages. 


The contents of this registry are: 


ID: An integer identifier to be used in the "int-id" attribute of a 
metadata/control <request> element. 


Message: The text of the message. Messages are listed in the 
registry in English; vehicles are expected to implement 
translations into languages supported by the vehicle. 


When new messages are added to the registry, the message text is 
determined by the registrant; IANA assigns the IDs. Each message is 
assigned a consecutive integer value as its ID. This allows an IVS 
to indicate by a single integer value that it supports all messages 
with that value or lower. The value 0 is reserved; usable messages 
start with 1. 


The initial set of values is listed in Table 2. 


$ A - - - - $5 5 ee + 
| ID | Message | 
+----4----------------------- - - - - 5 5 5 5 5 5 eee + 
| 0 | Reserved | 
| 1 | Emergency services has received your information and 

location but cannot speak with you right now. We will get 

help to you as soon as possible. 
+----4------------------------ - - - - - 5 5 5 5 eee + 


Table 2: Emergency Call Static Messages Registry Initial Values 
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14.5. Emergency Call Vehicle Lamp IDs Registry 


This document creates a new sub-registry called "Emergency Call 
Vehicle Lamp IDs" in the "Emergency Call Metadata/Control Data" 


registry established by [RFC8147]. This new sub-registry uniquely 
identifies the names of automotive lamps (lights). As defined in 
[RFC5226], this registry operates under "Expert Review" rules. The 


expert should determine that the proposed lamp name is clearly 
understandable and is sufficiently distinguishable from other lamp 
names. 


The contents of this registry are: 


Name: The identifier to be used in the "element-id" attribute of a 
metadata/control <request> element. 


Description: A description of the lamp (light). 


The initial set of values is listed in Table 3. 


+---------------- PO - = = + 
| Name | Description 

+---------------- FO O O - $= = + 
| head | The main lamps used to light the road ahead | 
| | | 
| interior | Interior lamp, often at the top center 

| | | 
| fog-front | Front fog lamps 

| fog-rear | Rear fog lamps 

| | | 
| brake | Brake indicator lamps 

| | | 
| brake-center | Center high-mounted stop lamp | 
| position-front | Front position/parking/standing lamps | 
| | | 
| position-rear | Rear position/parking/standing lamps | 
| | | 
| turn-left | Left turn/directional lamps 

| turn-right | Right turn/directional lamps 

| | | 
| hazard | Hazard/four-way lamps 

+---------------- FO O O O O = + 


Table 3: Emergency Call Lamp ID Registry Initial Values 
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6. Emergency Call Vehicle Camera IDs Registry 


This document creates a new sub-registry called "Emergency Call 
Vehicle Camera IDs" in the "Emergency Call Metadata/Control Data" 


registry established by [RFC8147]. This new sub-registry uniquely 
identifies automotive cameras. As defined in [RFC5226], this 
registry operates under "Expert Review" rules. The expert should 


determine that the proposed camera name is clearly understandable and 
is sufficiently distinguishable from other camera names. 


The contents of this registry are: 


Name: The identifier to be used in the "element-id" attribute of a 
control <request> element. 


Description: A description of the camera. 


The initial set of values is listed in Table 4. 
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4------------- EZ + 

| Name | Description 

Ho ooo- AZ + 

| backup | Shows what is behind the vehicle, e.g., often used | 

| | for driver display when the vehicle is in reverse. | 

| | Also known as rearview, reverse, rear visibility, | 

| | etc. | 
left-rear Shows view to the left and behind (e.g., left-side 

rearview mirror or blind spot view) 

| right-rear | Shows view to the right and behind (e.g., right- | 

| | side rearview mirror or blind spot view) 

| forward | Shows what is in front of the vehicle 

| rear-wide | Shows what is behind the vehicle (e.g., used by | 

| | rear-collision detection systems), separate from | 

| | backup view | 

| lane | Used by systems to identify road lane and/or 

| | monitor the vehicle’s position within lane 

| interior | Shows the interior (e.g., driver) | 

| night-front | Night-vision view of what is in front of the | 

| | vehicle | 

| night-rear | Night-vision view of what is behind the vehicle | 

| night-left | Night-vision view of what is to the left of the | 

| | vehicle | 
night-right Night-vision view of what is to the right of the 

vehicle 
4+------------- HZ + 


Table 4: Emergency Call Vehicle Camera IDs Registry Initial Values 
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7. The EmergencyCallData.VEDS INFO Package 


This document registers the EmergencyCallData.VEDS INFO package in 
the "Info Packages Registry". 


Both endpoints (the IVS and the PSAP equipment) include 
"EmergencyCallData.VEDS" in a Recv-Info header field per [RFC6086] to 
indicate the ability to receive SIP INFO messages carrying data as 
described here. 


Support for the EmergencyCallData.VEDS INFO package indicates the 
ability to receive NG-ACN-related body parts as specified in this 
document. 


A SIP INFO request message carrying data related to an emergency call 
as described in this document has an Info-Package header field set to 
"EmergencyCallData.VEDS" per [RFC6086]. 


The requirements of Section 10 of [RFC6086] are addressed in the 
following sections. 


7.1. Overall Description 


This section describes what type of information is carried in INFO 
requests associated with the INFO package and for what types of 
applications and functionalities User Agents (UAs) can use the INFO 
package. 


SIP INFO requests associated with the EmergencyCallData.VEDS INFO 
package carry data associated with emergency calls as defined in this 
document. The application is vehicle-initiated emergency calls 
established using SIP. The functionality is to carry vehicle data 
and metadata/control information between vehicles and PSAPs. 


7.2. Applicability 


This section describes why the INFO package mechanism, rather than 
some other mechanism, has been chosen for the specific use case. 


The use of the SIP INFO method is based on an analysis of the 
requirements against the intent and effects of the INFO method versus 
other approaches (which included the SIP MESSAGE method, SIP OPTIONS 
method, SIP re-INVITE method, media-plane transport, and non-SIP 
protocols). In particular, the transport of emergency call data 
blocks occurs within a SIP emergency dialog, per Section 7, and is 
normally carried in the initial INVITE request and its response; the 
use of the INFO method only occurs when emergency-call-related data 
needs to be sent mid call. While the SIP MESSAGE method could be 
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used, it is not tied to a SIP dialog as is the INFO method and thus 
might not be associated with the dialog. Both the SIP OPTIONS or 
re-INVITE methods could also be used, but they are seen as less clean 
than the INFO method. The SIP SUBSCRIBE/NOTIFY method could be 
coerced into service, but the semantics are not a good fit, e.g., the 
subscribe/notify mechanism provides one-way communication consisting 
of (often multiple) notifications from notifier to subscriber 
indicating that certain events in the notifier have occurred, whereas 
what’s needed here is two-way communication of data related to the 
emergency dialog. Use of media-plane mechanisms was discounted 
because the number of messages needing to be exchanged in a dialog is 
normally zero or very few, and the size of the data is likewise very 
small. The overhead caused by user-plane setup (e.g., to use the 
Message Session Relay Protocol (MSRP) as transport) would be 
disproportionately large. 


Based on the analyses, the SIP INFO method was chosen to provide for 
mid-call data transport. 


7.3. INFO Package Name 

The INFO package name is EmergencyCallData.VEDS. 

7.4. INFO Package Parameters 

None 

7.5. SIP Option-Tags 

None 

7.6. INFO Request Body Parts 

The body of an EmergencyCallData.VEDS INFO package is a multipart 
body containing zero or one application/EmergencyCallData.VEDS+xml 
parts (containing a VEDS data block), zero or more application/ 
EmergencyCallData.Control+xml (containing a metadata/control object) 
parts, and zero or one application/EmergencyCallData.eCall.MSD parts 
(containing an MSD). At least one VEDS, MSD, or metadata/control 


body part is expected; the behavior upon receiving a SIP INFO request 
with none is undefined. 


The body parts are sent per [RFC6086]; in addition, to align with how 
these body parts are sent in non-INFO messages, each associated body 
part is referenced by a Call-Info header field at the top level of 
the SIP message. The body part has a Content-Disposition header 
field set to "By-Reference". 
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A VEDS, metadata/control block, or MSD is always enclosed ina 
multipart body part (even if it would otherwise be the only body part 
in the SIP message). The outermost multipart that contains only body 
parts associated with the INFO package has a Content-Disposition 
value of "Info-Package". 


Service providers in the call path are not expected to add Additional 
Data [RFC7852] to SIP INFO requests (as they would to an initial 
INVITE request). 


14.7.7. INFO Package Usage Restrictions 


Usage is limited to vehicle-initiated emergency calls as defined in 
this document. 


14.7.8. Rate of INFO Requests 


The SIP INFO request is used within an established emergency call 
dialog to send requests, updated data, or an acknowledgment. Because 
requests are normally sent only on manual action of the PSAP call 
taker (who suspects some aspect of the vehicle state has changed) and 
updated data is sent only when an aspect of previously sent data has 
changed, the rate of SIP INFO requests associated with the 
EmergencyCallData.VEDS INFO package is normally quite low (most 
dialogs are likely to contain zero SIP INFO requests, while others 
can be expected to carry an occasional request). 


14.7.9. INFO Package Security Considerations 
The MIME media type registrations for the data blocks that can be 
carried using this INFO package contains a discussion of the security 
and/or privacy considerations specific to that data block. See 
Sections 12 and 13 for information on the security and privacy 
considerations of the data carried in vehicle-initiated emergency 
calls. 

14.7.10. Implementation Details 
See Sections 7 and 8 for protocol details. 


14.7.11. Examples 


See Section 11 for protocol examples. 
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